Congestion Avoidance and Energy Efficient Routing Protocol for WSN Healthcare Applications

Recent advances in wireless sensor technology facilitate the development of remote healthcare systems, which can significantly reduce the healthcare cost. The use of general and efficient routing protocols for Healthcare wireless sensor networks (HWSN) has crucial significance. One of the critical issues is to assure the timely delivery of the life-critical data in the resourceconstrained WSN environment. Energy, and some other parameters for HWSN are considered here. In this paper, a data centric routing protocol which considers end to end delay, reliability, energy consumption, lifetime and fairness have been taken into account. The Proposed protocol which is called HREEP (Healthcare REEP) provides forwarding traffics with different priorities and QoS requirements based on constraint based routing. We study the performance of HREEP using different scenarios. Simulation results show that HREEP has achieved its goals. 1Introduction Healthcare aware wireless sensor networks (HWSN) following wireless sensor networks have received great attention nowadays. Additive applications of these networks lead to an increase in their importance. Accessibility to low cost hardwares such as CMOS cameras and microphones has caused the expansion of healthcare aware wireless sensor networks. HWSN consists of wireless nodes which can transmit healthcare relevant traffic in addition to sensing healthcare relevant events. By developing hardwares, equipping small nodes with necessary devices is possible now [1,2]. Protocols which are designed for WSN lose a proportion of their efficiency if directly used for HWSN. But they still have so many similar characteristics. With respect to HWSN characteristics, their protocols should be designed in cross layer manner [3]. Many of those characteristics are mentioned below: Application dependency: Designing HWSN protocols is completely depended on its application. Application characteristics determine goals and crucial parameters. Energy consumption efficiency: like wireless sensor networks nodes, nodes which are designed for healthcare aware wireless sensor networks also have limited primary energy resources and they mostly can’t be recharged (or recharging node’s energy is not economically commodious) so energy consumption is still considered as a fundamental parameter. Capability of forwarding data with different real time requirements: for different reasons traffics with different priorities are forwarded in healthcare aware wireless sensor networks. Protocols should be capable of sending the traffics simultaneously and as a result each traffic achieves its own real time requirements. The ability of sending data with different reliabilities: healthcare aware wireless sensor networks’ traffics need different reliabilities. These networks protocols should be capable of sending these traffics. In this paper, we focus only on the issue of Routing in healthcare WSNs. In particular, we focus on large-scale medical disaster response applications. The Proposed protocol HREEP (Healthcare REEP) which is a data centric routing protocol takes end to end delay, reliability, energy consumption, network lifetime and fairness into consideration. As is known, all of the aforementioned parameters are not independent; for example energy consumption and network lifetime are inversely related. The main goal of the proposed protocol is to control these parameters using constraint based routing process. Parameters which are important for HREEP are also important for wireless sensor networks, too. But with respect to the fact that HWSNs are a subset of WSNs, parameters are more commensurate with HWSN [4]. Depending on their application, the delay parameter has different importance for HWSNs. In real time applications, information should reach destination in an appropriate time otherwise its importance decreases (in hard real time application receiving data out of legal interval is valueless). Another point worth mentioning is that different data types have different delay thresholds; therefore network reaction should be commensurated with data types. Energy consumption, lifetime and fairness are relevant parameters to protocol’s energy efficiency. Indeed life time increment is the essential goal; however two main elements for increasing lifetime is consuming energy efficiently and performing fairness. The aim to perform fairness is consuming energy of network nodes fairly. When network node’s energy has less variance, network lifetime will be prolonged. To perform fairness, nodes’ energy should be used equally. If one part of a network is used more than other parts, its energy will decrease sooner than others and then the network will be partitioned. If a network is partitioned, its energy consumption increases severely. Using different paths to send data to sink makes the fairness performance better. When network lifetime is prolonged, apparently we can use its services longer [5]. The Proposed protocol is composed of the following 4 phases; request dissemination, event occurrence report, route establishment and data forwarding. The rest of the paper is organized as follows: in section 2 related works will be discussed. In section 3, HREEP is presented in detail. In section 4, we will evaluate proposed protocol efficiency and finally in section 5 we conclude the paper. 2Related works HREEP is a data centric protocol. Data centric protocols are a major part in different routing protocols in wireless sensor networks [2,3]. Many successful routing protocols are presented for WSNs and HWSNs hitherto. Directed Diffusion and SPIN are two famous routing protocols for WSNs, which have received attention. In both, requests are disseminated in network and routing is done based on data type. Each of the aforementioned protocols is improved many times, as they are known as family; for example [7]. SPIN has many flows; for example it is not scalable, it is not energy efficient and etc. Healthcare aware wireless sensor networks routing protocols uses different methods to perform their tasks. HREEP makes routes based on network conditions and traffic requirements at the same time. The Proposed protocol has used many of ideas which are pointed to in REEP[8]. REEP protocol has different phases like other data centric protocols. The Mentioned phases are: Sense event propagation, Information event propagation and Request event propagation. In Sense event propagation phase sink sends its requests to all of the network nodes. In Information event propagation phase each node sends its sensed data to the sink. In next phase which is entitled Request event propagation sink responses to all of the nodes which send their sensed data and during this communications routes are established. This plan phasing is almost similar to data centric routing protocols[9][10][11]. 3The proposed protocol Data centric protocol HREEP is composed of the following 5 different phases: Request Propagation dissemination, event occurrence report, route establishment, data forwarding and route recovery. The Proposed protocol structure is shown in fig.1. In phase 1, sink floods its request to entire network nodes. Phase 1 will be discussed in section 3.1. Then four other phases, event occurrence report, route establishment, data forwarding and route recovery, are presented in details in sections 3.2, 3.3, 3.4 and 3.5 respectively. Figure1. Proposed protocol structure Phase1: Request Propagation Phase2: Event Report Phase3: Route establishing Phase4: Data transmission Phase5: Route Recovery We have designed the proposed protocol based on healthcare aware wireless sensor networks characteristics. These networks are used for different applications [6]. Using one network for different applications is economical, because different applications are performed using one hardware infrastructure and this leads to a decrease in cost. Proposed protocol can send traffics with different QoS requirements. For more tangible discussion, we will present an example. Assume that HWSN is used to monitor one patient. There are two traffics in the mentioned network. To monitor vital limbs, high priority report should send to sink through network. But for other events (for example periodical events to monitor other limbs), network nodes use low priority traffic. 3-1Request dissemination phase In this phase sink should flood its requests to entire network nodes. Following points should be considered for this phase packets: Priority of used application; in HWSN a network may be used for forwarding more than one traffic with different characteristics. Therefore, traffic priority should be specified before forwarding. Time; it is possible that many packets which belong to one application are propagated through network in different times. Therefore, forwarding time should be specified in all packets. Furthermore, many of request have lifetime; when lifetime expires the aforementioned request is not valuable any more. Destination nodes geographical confine; this field is not vital for application that the requests should be sent to the entire network nodes. Request specification; each request contains destination nodes task and the way they should react to the event. 3-2Event occurrence report phase When Request dissemination phase is done, the entire network nodes know their task. When a node senses an event relevant to its task, it should report the sensed event features to the sink. Node should necessarily regard all the specifications which are outlined in task characteristics in its report so that the sink can react properly. In this phase the relevant information to the occurred event will be sent to the sink but sending of the fundamental information relevant to the event will be done in the data sending phase. Furthermore the very phase paves the way for providing packet routing. With this end in mind a packet will be created by a node and the relevant data to the sensed event will be located there. Through sending the packet to the sink the necessary routing tables will be provided for the aim of data routing in the nodes. The final routing will be executed in the route establishment phase. Indeed in the second phase in each node the completion of the final routing will be done by gathering all the essential information in each node in the form of permanent routing table. This act will end in the creation of routing tables for each specific node in the third phase. When an event is sensed by a node, according to its task it should be reported to the sink. The node will send the packet to all its neighbors by the time it is created (this packet is called the second phase packet). If the nodes are aware of their situations the packet will be sent to the neighbors who are far closer than the sending node to the sink. Although this matter leads to a decrease in the protocol’s energy consumption, considering the need for localization process, it can’t be implemented everywhere. It is to be noted that in the application which the request should be sent to one part of the network the nodes are certainly aware of their situations. By receiving the second phase packet each node creates a record in a routing table which is titled the second phase table. In this record the packet’s priority (compatible with traffic priority and the specified event), source node, sending node, the length of the traversed path, the numbers of traversed hops are kept. In the proposed protocol each node owns an ID which is located in all the sent packet. The traversed route is the sum of the routes the packet has taken from the source node to the current node. After inserting a record, the node will send a packet to all its neighbors. This procedure will continue until the packet reaches the sink. We have to bear in mind having more than one record is more likely from one certain source node in the second phase table. This is due to the different routes which a node can be reached by the second phase packet but the packets which have the same field will be ignored. At the end of the second phase each node owns a routing table named the second phase table which will be used for determining the final route in the third phase. The records of the second phase table dictate the possible ways between the specified node and the event sensor source node. 3-3Route establishment phase After the sink received all the second phase packets, it sends back and acknowledge packet (this packet is called the third packet phase) to the source node announcing to send all its gathered data to the sink. It is possible for an event to be sensed by more than a sensor node. At this stage according to the sent data by the source node, the sink chooses one or more nodes for the final data sending. In the second phase packet, each packet specifies its own sensing accuracy. For instance, in the healthcare applications, the received vital signals specify the sensing accuracy. According to mentioned notes a sensor should be chosen for reporting the sensed events. After choosing the source node, the third phase packet will be sent to its destination. As the third phase packet traverses the path, it creates the third phase table in the middle nodes. The third phase routing table is the final routing table which made the sent data routing possible from the source node. The sending acknowledgement depends on the sensed event priority. Two different acknowledgements are considered, acknowledgement for high priority (real time traffic) and acknowledgement for low priority (non real time traffic). The sink evaluates the second phase routing table for sending the acknowledgement with high priority. The first record will be chosen for the sending acknowledgement. The second phase packets will be located in the second phase routing table according to the time. Whenever a node receives the second type packet, it will locate it in the first available record. In fact the order of records ́ numbers in the second phase routing table specifies the order of the time which they were received. Due to the great importance of time for real time applications the first record of the second phase table will be chosen. It is worth mentioning that the first record was first created in terms of time. But records selection in the source node is always of great importance. The only records will be considered that their source node is the very node which is chosen by the sink. Every node constitutes two tables in the second phase. Phase three routing table, for high priority traffics and routing table for low priority traffics. During this phase, these two tables are completed. When a node in phase three receives a packet with high priority, a record for that in the routing table of phase with a high priority is created. In this table the following parameters are placed: The sending node, the receiving node, the source node and the type of function. According to what was mentioned, every node chooses the first record from the routing table in phase two as the next hop for the packet in phase three with high priority. This process continues until the packet arrives at its source. In fact, at the end of the third phase in the third phase non real time routing table, for every source one record is placed. Concepts which were mentioned in current section concerned traffic with a high priority. In the rest of the section finding low priority table in phase three will be elucidated. The sink considers the records relating to the source, among the routing records of phase two. For each of the records the probability of i P is calculated through